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:
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'
does that
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 Java 1.5/1.6 support hex floating-point
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, [...]
___
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
be both
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's
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)
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 also
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:
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.
Are you
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
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,
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 in
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, the
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
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()
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
guarantees that a
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
ret
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
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://mail.python.org
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-of-2
[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
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: Binary
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
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 I
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 assert to
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 way
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 anything
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 52 or 56 for VAX.)
Quick
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
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
On Sun, Dec 14, 2008 at 9:06 PM, Martin v. Löwis mar...@v.loewis.de 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
On Fri, Jun 25, 2010 at 7:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Hello all,
I've put a recipe up on the Python cookbook for creating APIs that work as
both decorators and context managers and wonder if it would be considered a
useful addition to the functools module.
On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl g.bra...@gmx.net wrote:
So -- if every dev adopted a Tool or Demo, that would be quite a
manageable piece of work, and maybe a few demos can be brought up
to scratch instead of be deleted.
I'll go ahead and promise to care for the Demo/classes
On Sun, Jun 27, 2010 at 12:37 AM, M.-A. Lemburg m...@egenix.com wrote:
Brett Cannon wrote:
On Wed, Jun 23, 2010 at 14:53, Brett Cannon br...@python.org wrote:
I finally realized why clang has not been silencing its warnings about
unused return values: I have -Wno-unused-value set in CFLAGS
On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin jyass...@gmail.com wrote:
AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based
systems
(http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842).
If Python's configure.in sets an otherwise-empty
On Sun, Jun 27, 2010 at 9:37 PM, Jeffrey Yasskin jyass...@gmail.com wrote:
On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson dicki...@gmail.com wrote:
I think saving and restoring CFLAGS across AC_PROG_CC was attempted in
http://bugs.python.org/issue8211 . It turned out that it broke OS X
On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg m...@egenix.com wrote:
On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin jyass...@gmail.com wrote:
On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson dicki...@gmail.com wrote:
I'm not sure I understand the importance of allowing AC_PROG_CC to set
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg m...@egenix.com wrote:
Why do you think that the default -O2 is unwanted
Because it can cause debug builds of Python to be built with
optimization enabled, as we've already seen at least twice.
and how do you know
whether the compiler accepts -g
On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg m...@egenix.com wrote:
Mark Dickinson wrote:
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg m...@egenix.com wrote:
Why do you think that the default -O2 is unwanted
Because it can cause debug builds of Python to be built with
optimization
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro craigci...@gmail.com wrote:
Ok, I'm obviously being silly here, but sure you can:
dis.dis(raise TypeError())
0 114 26977
3 115 8293
6 IMPORT_STAR
7 SETUP_EXCEPT 25968 (to 25978)
On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro craigci...@gmail.com wrote:
dis.dis(raise TypeError())
0 114 26977
3 115 8293
6 IMPORT_STAR
7 SETUP_EXCEPT 25968
On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano st...@pearwood.info wrote:
Craig, what are you using to get that? When I try it in Python 3.1, I
get:
TypeError: don't know how to disassemble str objects
How do you get that result?
As I just discovered (see above), dis.dis is happy to
On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro craigci...@gmail.com wrote:
Whoa. That's very peculiar looking bytecode. Is dis.dis behaving as
it should here?
BTW, I think you want 'raise TypeError', not 'raise TypeError()'.
Yep, that's embarrassing. I was being lazy: I was expecting
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson benja...@python.org wrote:
This is just a note that we have one bug blocking 2.7 final at the
moment: http://bugs.python.org/issue9144
I've just made http://bugs.python.org/issue7673 a release blocker too,
I'm afraid. It's a potential security
On Sun, Jul 4, 2010 at 9:45 PM, Jesse Noller jnol...@gmail.com wrote:
On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote:
Now that
On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald wal...@livinglogic.de wrote:
http://coverage.livinglogic.de/ *does* include coverage info for stuff
written in C, see for example:
http://coverage.livinglogic.de/Objects/unicodeobject.c.html
However it *is* strange that test_audioop.py gets
While looking at a parser module issue
(http://bugs.python.org/issue9154) I noticed that Python's grammar
doesn't permit trailing commas after keyword-only args. That is,
def f(a, b,): pass
is valid syntax, while
def f(*, a, b,): pass
is not. I was just curious whether the latter
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland di...@microsoft.com wrote:
Terry wrote:
This violates the important principle that allowed def and call arg
sequences should match to the extent sensible and possible. In this
sense, the SyntaxError is a bug. So I would fix this now for 3.2 and
On Sat, Jul 10, 2010 at 1:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
+1 for fixing it from me, unless any of the other implementations object.
@Mark: my comment on the tracker issue had an implied ...unless you
really want to on the end :)
Thanks! Patch at http://bugs.python.org/issue9232
On Mon, Jul 12, 2010 at 10:19 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan petre.ga...@gmail.com wrote:
ival should not be resolved through PyLong_AsLong, but through
functionality/interface like PyNumber_Long
+1, but I'd prefer it if PyNumber_Index
Now that we've got the short float repr in Python, there's less value
in having float.__str__ truncate to 12 significant digits (as it
currently does). For Python 3.2, I propose making float.__str__ use
the same algorithm as float.__repr__ for its output (and similarly for
complex).
Apart from
On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote:
Now that we've got the short float repr in Python, there's less value
in having float.__str__ truncate to 12 significant digits (as it
currently does
2010/8/7 Kristján Valur Jónsson krist...@ccpgames.com:
Hi there.
[...]
But it appears that the builtin round() method also changed. Whereas I see
the changing of floating point representation in string formatting as not
being very serious, why did the arithmetic function round() have to
2010/8/7 Mark Dickinson dicki...@gmail.com:
2010/8/7 Kristján Valur Jónsson krist...@ccpgames.com:
Hi there.
[...]
But it appears that the builtin round() method also changed. Whereas I see
the changing of floating point representation in string formatting as not
being very serious, why did
On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden m...@timgolden.me.uk wrote:
Thanks to whoever's been working on the new Summary lists on the Issue
Tracker.
Ezio Melotti, I assume.
The Followed by you / Created by you / Assigned to you are just what
the doctor ordered.
Agreed. Now I can get rid
On Wed, Aug 11, 2010 at 4:09 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
On 11/08/2010 17.59, Mark Dickinson wrote:
One niggle: we seem to have lost the simple 'Open Issues' search
under 'Summaries' on the left-hand side of the page.
I was expecting someone to complain about it.
Glad
On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hello,
I would like to see “unit test needed” removed from the workflow menu in
the bug tracker. The reason is that we don't do test-driven development
(or, at least, most of us don't) and this stage entry is
On Thu, Aug 19, 2010 at 7:11 AM, Timothy Kinney
timothyjkin...@gmail.com wrote:
I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.
If I run the following:
[code]
from pylab import randint
for s in range(100):
print randint(0,1)
[/code]
I get 100 zeroes.
If I
On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
In CPython, the builtin max() and min() have the property that if there
are items with equal keys, the first item is returned. From a quick look
at their source, I think this is true for Jython and IronPython too.
On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin jyass...@gmail.com wrote:
Actually, Decimal isn't doing anything along these lines. At least in
Python 2.6, I get:
Decimal('2').max(Decimal('2.0'))
Decimal('2')
Decimal('2.0').max(Decimal('2'))
Decimal('2')
Decimal('2.0').min(Decimal('2'))
On Tue, Sep 7, 2010 at 10:40 PM, Jeffrey Yasskin jyass...@gmail.com wrote:
Decimal may actually have this backwards. The idea would be that
min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a
stable sort, then, max of equivalent elements would return the last
element, and
On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin jyass...@gmail.com wrote:
It's ignoring the order of the arguments. It also creates
a new Decimal object for the return value, so I can't use id() to
check which one
On Tue, Sep 7, 2010 at 11:00 PM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin jyass...@gmail.com wrote:
It's ignoring the order of the arguments. It also creates
a new Decimal
On Fri, Nov 12, 2010 at 9:29 AM, Martin v. Löwis mar...@v.loewis.de wrote:
As you may have noticed: I updated the buildbot master to release 0.8.2.
If you notice any problems, please post them here.
One effect of this change seems to be that bbreport[1] no longer
works, since it appears that
On Thu, Dec 2, 2010 at 8:23 PM, Martin v. Löwis mar...@v.loewis.de wrote:
In the case of number parsing, I think Python would be better if
float() rejected non-ASCII strings, and any support for such parsing
should be redone correctly in a different place (preferably along with
printing of
On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou solip...@pitrou.net wrote:
Er, normally you don't need *any* Python installed to build Python (be
it 3.x or 2.x).
Are you sure about this? I remember needing an existing Python to
building Python 2.7 on a new python-less install of FreeBSD a
On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson dicki...@gmail.com wrote:
On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou solip...@pitrou.net wrote:
Er, normally you don't need *any* Python installed to build Python (be
it 3.x or 2.x).
Are you sure about this? I remember needing an existing
On Sat, Dec 4, 2010 at 1:40 PM, Benjamin Peterson benja...@python.org wrote:
You have to touch Include/Python-ast.h and Python/Python-ast.c. We do
this for release tarballs.
Ah, that makes sense. Thanks.
Mark
___
Python-Dev mailing list
On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray rdmur...@bitdance.com wrote:
It seems like the status quo is fine. I wouldn't object to it being
made more consistent. I would object to removing the existing cases.
Same here, on all three counts. In one of the projects I'm currently
working
On Fri, Dec 24, 2010 at 1:08 AM, Nick Coghlan ncogh...@gmail.com wrote:
def __index__(self):
- index(self)
+ someobject[self]
return int(self)
Changing the docstring to say operator.index(self) would be the
clearest solution here.
Agreed. Certainly
On Mon, Dec 27, 2010 at 9:43 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition.
[...]
-1 for assignment in nonlocal and global statements from me, too.
Mark
___
On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan ncogh...@gmail.com wrote:
Currently [1], the implementation and the documentation for PEP 3118's
Py_buffer struct don't line up (there's an extra field in the
implementation that the PEP doesn't mention).
I think there are actually two such fields:
On Wed, Jan 5, 2011 at 2:03 PM, Mark Dickinson dicki...@gmail.com wrote:
Maybe I'm misunderstanding. What's the responsibility of a buffer
export w.r.t. the obj field---i.e., what should 3rd party code be
Grr. *buffer exporter*, not *buffer export*.
Mark
On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 5 Jan 2011 12:55:55 +
Mark Dickinson dicki...@gmail.com wrote:
The need for obj is a little ugly: as far as I can tell, it's
meaningless for a 3rd-party object that wants to export buffers---it's
only
On Thu, Mar 10, 2011 at 2:17 AM, Eugene Toder elto...@gmail.com wrote:
Indeed, see http://bugs.python.org/issue11244
Yes, I've noticed that too. However, if I'm not missing something, your
patches
do not address folding of -0.
Hmm, it seems that way. Could you post a comment on the tracker
FWIW, I'm -1 on backing out Antoine's patch. In addition to fixing
the minor optimization regression, it makes the peepholer
significantly more consistent in what it can and can't fold. One of
the first times that I delved into the peepholer code was to try to
understand why expressions like: 2
On Tue, Apr 12, 2011 at 6:01 PM, Djoume Salvetti dsalve...@trapeze.com wrote:
Thank you and sorry about the pastebin.
I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 3.1.2
(all in ubuntu). I'll open a bug.
Is http://bugs.python.org/issue5215 the same issue?
Mark
On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
The other day I was surprised to learn this:
nan = float('nan')
nan == nan
False
[nan] == [nan]
True # also True in tuples, dicts, etc.
That one surprises me a bit too: I knew we were using
On Wed, Apr 27, 2011 at 7:41 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
One issue that I don't fully understand: I know there is only one instance
of None in Python, but I'm not sure where to discover whether there is only
a single, or whether there can be multiple, instances of NaN or
On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
History, I think. There's a c.l.p. message from Tim Peters somewhere
saying something along the lines that he'd love
Hi Michael,
Sorry for the late reply; it's been kinda busy around here.
If there are places left, I'll definitely be there at the summit.
Congratulations on your impending doom! (And sorry to hear that you
might not be there in Florence.)
Mark
On Sat, Apr 16, 2011 at 3:50 PM, Michael Foord
On Mon, Jun 20, 2011 at 1:31 PM, Antoine Pitrou solip...@pitrou.net wrote:
Maciej Fijalkowski fij...@gmail.com a écrit :
Unfortunately I'm missing Europython (and language summit) this year.
Did anyone do a writeup on what was discussed?
Mark Dickinson has been taking notes, but since
the
topics that we discussed below.
Present:
Antonio Cuni
Mark Dickinson
Larry Hastings (chair)
Marc-André Lemburg
Ezio Melotti
Antoine Pitrou
Armin Ronacher
Armin Rigo
Mark Ramm
Topics covered
==
Python 3 adoption
On Thu, Sep 29, 2011 at 2:45 AM, Victor Stinner
victor.stin...@haypocalc.com 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
The PEP and code look generally good to me.
I think the API for median and its variants deserves some wider discussion:
the reference implementation has a callable 'median', and variant callables
'median.low', 'median.high', 'median.grouped'. The pattern of attaching
the variant callables as
On Thu, Aug 15, 2013 at 2:25 AM, Steven D'Aprano st...@pearwood.infowrote:
Can I request that people please look at this issue, with an aim to ruling
on the PEP and (hopefully) adding the module to 3.4 before feature freeze?
If it is accepted, I am willing to be primary maintainer for this
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.infowrote:
- Each scheme ended up needing to be a separate function, for ease of both
implementation and testing. So I had four private median functions, which I
put inside a class to act as namespace and avoid polluting the main
median; m = median(my_data) should still
work in the simple case.
Mark
Steven D'Aprano st...@pearwood.info wrote:
On 15/08/13 21:42, Mark Dickinson wrote:
The PEP and code look generally good to me.
I think the API for median and its variants deserves some wider discussion
On Sun, Feb 16, 2014 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
The practical benefits of this kind of change in the test suite are
also highly dubious, because they *only help if the test fails at some
point in the future*. At that point, whoever caused the test to fail
will switch
On Sun, Jul 15, 2012 at 1:36 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 15 Jul 2012 18:47:38 +1000
Nick Coghlan ncogh...@gmail.com 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
On Mon, Sep 10, 2012 at 9:06 PM, Matti Picus matti.pi...@gmail.com 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,
101 - 200 of 375 matches
Mail list logo
