On Sat, Mar 27, 2010 at 12:59 AM, Michael Foord
wrote:
> Hello all,
>
> A user has suggested an optional argument to
> unittest.TestCase.assertAlmostEqual for specifying a maximum difference
> between the expected and actual values, instead of using rounding.
+1.
Mark
___
On Mon, Mar 22, 2010 at 7:52 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
> wrote:
>> One other thought.
>>
>> The Decimal constructor should now accept floats as a possible input type.
>> Formerly, we separated that out to Decimal.from_float() because
>> deci
On Fri, Apr 2, 2010 at 3:54 PM, Stefan Krah wrote:
>
> I looks like the 'stop build' button can a) cause subsequent builds to fail
> and b) cause pending builds to be deleted from the queue.
>
>
> a) http://www.python.org/dev/buildbot/builders/ARM Linux EABI 3.x/builds/18
> was apparently interr
On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven
wrote:
> Before I file a bug report, is anyone else seeing this (in my case on
> FreeBSD 8):
>
> Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first
> unrecognized character is `@'
> Modules/_ctypes/libffi/src/
On Fri, Apr 16, 2010 at 9:04 AM, Hagen Fürstenau wrote:
>> This behavior seems pretty strange to me, indeed PyPy gives the
>> TypeError for both attempts. I just wanted to confirm that it was in
>> fact intentional.
>
> Oleg already answered why f(**{1:3}) raises a TypeError. But your
> question
On Fri, Apr 16, 2010 at 3:33 PM, Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan wrote:
>> I would agree with leaving it implementation defined - I don't think
>> either PyPy or CPython should be forced to change their current
>> behaviour in relation to this. A minor note
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>
>> Can this sneak in under the 'incorrect language semantics' exemption
>&g
On Sat, Apr 17, 2010 at 7:41 PM, Victor Stinner
wrote:
> Ezio and Florent are developing a tool called bbreport to collect buildbot
> results and generate short reports to the command line. It's possible to
> filter results by Python branch, builder name, etc. I send patches to link
> failed tests
On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
> While talking about Python 2.6 -> 2.7 transitions, the subject of relative and
> absolute imports has come up. PEP 328 states that absolute imports will be
> enabled by default in Python 2.7, however I cannot verify that this has
> actually h
On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson wrote:
> On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
>> While talking about Python 2.6 -> 2.7 transitions, the subject of relative
>> and
>> absolute imports has come up. PEP 328 states that absolute imports will
On Thu, May 6, 2010 at 4:52 AM, Joao S. O. Bueno wrote:
> On Wed, May 5, 2010 at 9:59 PM, Eric Smith wrote:
>> That's my point. Since it's basically unreviewable, is it smart to do it
>> during a beta?
>
> Hello folks -
> I don't think these modifications are that "unreviewable": the
> generated
On Tue, May 18, 2010 at 11:00 PM, Gustavo Narea wrote:
> I've checked the new collections.Counter class and I think I've found a bug:
>
>> >>> from collections import Counter
>> >>> c1 = Counter([1, 2, 1, 3, 2])
>> >>> c2 = Counter([1, 1, 2, 2, 3])
>> >>> c3 = Counter([1, 1, 2, 3])
>> >>> c1 == c2
On Thu, May 20, 2010 at 10:18 PM, Mark Dickinson wrote:
> See also this recent thread on python-list, and in particular the messages
> from Raymond Hettinger in that thread:
>
> http://mail.python.org/pipermail/python-list/2010-March/thread.html
Sorry, bad thread link.
On Wed, May 26, 2010 at 10:15 AM, Colin H wrote:
> issue991196 was closed being described as intentional. I've added
> a comment in that issue which argues that this is a serious bug (also
> aserted by a previous commenter - Armin Rigo), because it creates a
> unique, undocumented, oddly behavi
On Fri, Jun 25, 2010 at 7:35 PM, Michael Foord
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.
> http://code.activestate.com/r
On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl 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" subdir.
B
On Sun, Jun 27, 2010 at 12:37 AM, M.-A. Lemburg wrote:
> Brett Cannon wrote:
>> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
>>> I finally realized why clang has not been silencing its warnings about
>>> unused return values: I have -Wno-unused-value set in CFLAGS which
>>> comes before OPT
On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin 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 CFLAGS to -g b
On Sun, Jun 27, 2010 at 9:37 PM, Jeffrey Yasskin wrote:
> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson 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
>> universal b
On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg wrote:
>> On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote:
>>> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson 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 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 as option ?
On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg wrote:
> Mark Dickinson wrote:
>> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote:
>>> Why do you think that the default -O2 is unwanted
>>
>> Because it can cause debug builds of Python to be built with
>
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro 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)
> 10
On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson wrote:
> On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro wrote:
>>
>>>>> dis.dis("raise TypeError()")
>> 0 <114> 26977
>> 3 <115> 8293
>>
On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano 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 interpret byte
stri
On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro 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 different
> bytecod
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson 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 vulnerability in t
On Sun, Jul 4, 2010 at 9:45 PM, Jesse Noller wrote:
> On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé wrote:
>> On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote:
>>> On 4 July 2010 17:02, Benjamin Peterson wrote:
Now that Python 2.7 is out, I'd like to thank a few of the people who
made i
On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald 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 executed, but
> au
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 was
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland 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
>> notify the ot
On Sat, Jul 10, 2010 at 1:22 AM, Nick Coghlan 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
Mark
___
On Mon, Jul 12, 2010 at 10:19 PM, Nick Coghlan wrote:
> On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan 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 were used, rather than PyNumber_Long
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 si
On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger
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
>>
2010/8/7 Kristján Valur Jónsson :
> 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 change?
This was par
2010/8/7 Mark Dickinson :
> 2010/8/7 Kristján Valur Jónsson :
>> 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
On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden 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 of my own
On Wed, Aug 11, 2010 at 4:09 PM, Ezio Melotti 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 some
On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou 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 therefore
> useless a
On Thu, Aug 19, 2010 at 7:11 AM, Timothy Kinney
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 import ran
On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
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.
It's actually not cl
On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin 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'))
> D
On Tue, Sep 7, 2010 at 10:40 PM, Jeffrey Yasskin 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 min the first.
Y
On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson wrote:
> On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin 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 o
On Tue, Sep 7, 2010 at 11:00 PM, Mark Dickinson wrote:
> On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson wrote:
>> On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote:
>>> It's ignoring the order of the arguments. It also creates
>>> a new Decimal object for
On Fri, Nov 12, 2010 at 9:29 AM, "Martin v. Löwis" 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 buildbot 0.8.2 ha
On Thu, Dec 2, 2010 at 8:23 PM, "Martin v. Löwis" 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 numbers).
+1.
a bit embarrassing if they fail for some inputs.
One more thing: since this is my first post to python-dev I should
probably introduce myself. I'm a mathematician, working mostly in
number theory. I learnt programming and numerical analysis the hard
way, coding service-life prediction algorit
On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou 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 couple
of months ago.
On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:
> On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou 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 Pytho
On Sat, Dec 4, 2010 at 1:40 PM, Benjamin Peterson 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
Python-Dev@python.org
http://m
On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray 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, we've settled on
On Fri, Dec 24, 2010 at 1:08 AM, Nick Coghlan 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 "someobj
On Mon, Dec 27, 2010 at 9:43 AM, Raymond Hettinger
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
___
Python-Dev mailing list
Python-De
Bah. I meant to send this to the list. (I suspect that Nick also
meant to send his reply to the list.)
On Mon, Dec 27, 2010 at 12:43 PM, Mark Dickinson wrote:
> On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan wrote:
>> The symmetry only breaks for a class that breaks the invariant:
.. and here's my original reply to Nick, which was also intended to go
to the list. Sorry, folks.
Mark
-- Forwarded message --
From: Mark Dickinson
Date: Mon, Dec 27, 2010 at 10:27 AM
Subject: Re: [Python-Dev] Range __contains__ and objects with __index__ methods
To:
On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan 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: smalltable and
On Wed, Jan 5, 2011 at 2:03 PM, Mark Dickinson 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 *buffe
On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou wrote:
> On Wed, 5 Jan 2011 12:55:55 +
> Mark Dickinson 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
>>
On Thu, Mar 10, 2011 at 2:17 AM, Eugene Toder 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 issue
about
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 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 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
identity-th
On Wed, Apr 27, 2011 at 7:41 PM, Glenn Linderman 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 Inf. The
> IEEE 754
On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing 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 to make (e.g.,) 1e300
* 1e
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 wrote:
> Maciej Fijalkowski 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,
e outlined 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 9/17/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> In the Tracker Issue...
>
> http://bugs.python.org/issue1772851
>
> ... Mark Dickinson came with a patch that alters in a very corner case
> how the hash is calculated to a long integer.
>
Much as I'
On 10/2/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/10/2, Raymond Hettinger <[EMAIL PROTECTED]>:
>
> > Yes! We have guaranteed that spec updates are to be treated as bug
> fixes and backported. This is especially important in this case
> > because other errors have been fixed and the
On 10/15/07, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> [...] I
> would like to know if there is still interest in C version of Decimal.
> If so - should I write PEP, or just code and 'we'll see later'?
I'd be happy to see decimal.py replaced by a C version giving
essentially the same functiona
On 10/16/07, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> Well, I am pretty sure, that addition works in linear time in Python
> version :>.
Unfortunately not. Here are some timings from my laptop:
>>> from timeit import Timer
>>> Timer("x+x", "from decimal import Decimal; x =
Decimal('1'*5000)
On 10/16/07, Fredrik Johansson <[EMAIL PROTECTED]> wrote:
> There is another alternative, which is to use integers exclusively for
> both representation and arithmetic, and only compute an explicit digit
> tuple or string in special cases. I'm doing this in in mpmath
> (http://code.google.com/p/mpm
On 10/16/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 10/16/07, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > the reverse conversion to get a Decimal result; both of these
> > conversions (tuple of digits <-> integer) take time quadratic in the
> >
On Jan 4, 2008 11:14 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008 4:40 AM, Facundo Batista <[EMAIL PROTECTED]> wrote:
> > Do you mean that the response in the following case is of type "float"?:
> >
> > >>> round(decimal.Decimal("2.5"))
> > 3.0
>
> Yes.
>
That seems a little pe
On Jan 5, 2008 5:54 PM, <[EMAIL PROTECTED]> wrote:
> At first I didn't realize why I'd missed this feature. While the
> rounding *modes* are well documented, though, after 20 minutes of
> reading documentation I still haven't found a method or function that
> simply rounds a decimal to a given si
Hello all,
I've recently been granted commit privileges; so, following the usual
protocol, here's a quick introduction. I'm a mathematician by day; my
degree is in number theory, but five summers of Fortran 77 programming and
two semesters of teaching numerical analysis have given me a taste for
On Jan 19, 2008 3:06 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> In the Rational class that I've recently checked into Python 2.6
> (http://bugs.python.org/issue1682), it might be nice to provide a
> method that, given a particular rational number, returns a nearby
> number that's nicer in so
On Jan 21, 2008 3:44 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/01/2008, Tim Peters <[EMAIL PROTECTED]> wrote:> By "useful" I
> don't mean lots of people will use it ;-) I mean /some/
> > people will use it -- a way to generate the sequence of convergents is
> > a fundamental tool that can
A request for information:
What non IEEE 754 platforms exist that people care about running Python 2.6,
Python 3.0 and higher on?
By non IEEE 754 platform, I mean a platform where either the C double is not
the usual 64-bit IEEE floating-point format, or where the C double is IEEE
format but the p
On Feb 1, 2008 7:56 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Mostly. For VAX, there exist two double formats: the D format, and the
> G format - not sure whether you counted them as two.
>
I didn't. Thanks.
> They run Linux, so yes. Notice that other people also run Python on z/OS.
>
On Feb 1, 2008 8:04 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I spoke to Mikko Ohtamaa (Moo-- on #pys60) and he gave me the name of a
> Nokia developer and this link
> http://discussion.forum.nokia.com/forum/showthread.php?t=97263. I
> already contacted the developer and asked him to reply
On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I've just filed issue2114 (http://bugs.python.org/issue2114) because
> test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.
It looks like you've got a file Lib/test/decimaltestdata/normalize.decTest
(or poss
On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Also, it would be useful to have a new method, float.is_integer(). This
> would be better than the current approach where we make the
> test: if x == floor(x).
>
How common is this test? Given the inexact nature of
Dear all,
I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch. Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least some of this
work into Python 2.6/3.0. Most of the changes are completed
Apologies for the bad formatting. Here's a repost with shorter lines.
Dear all,
I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch. Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least
Aargh. Extra long lines again. Here's a repost.
An update: after some discussion, we're planning a PEP for the "with
ieee754"
and related ideas, perhaps aimed at Python 3.1; there are lots of difficult
decisions to be made, and plenty that would benefit from community feedback.
In the meantim
An update: after some discussion, we're planning a PEP for the "with
ieee754" and related ideas, perhaps aimed at Python 3.1; there are lots of
difficult decisions to be made, and plenty that would benefit from community
feedback. In the meantime, we'll get the rest of the fixes/additions tidied
On Feb 17, 2008 2:42 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> There are some modules like Decimal that make a promise to run on earlier
> versions of Python. In those cases only the first change (backwards
> compatible)
> should be made. Our 5,000 line Decimal package will need to wait
On Feb 17, 2:42 pm, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> There are some modules like Decimal that make a promise to run on earlier
> versions of Python. In those cases only the first change (backwards
> compatible)
> should be made. Our 5,000 line Decimal package will need to wait fo
On Thu, Mar 13, 2008 at 4:20 AM, Imri Goldberg <[EMAIL PROTECTED]> wrote:
> My suggestion is to do either of the following:
> 1. Change floating point == to behave like a valid floating point
> comparison. That means using precision and some error measure.
> 2. Change floating point == to raise an
On Sun, Mar 16, 2008 at 1:32 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> I think this is possible, though considerable work. Probably the
> biggest win will be creating a mock for socket and using mock sockets
> in the tests for asyn{core,chat}, smtplib, xmlrpc, etc. That will fix
> about 75%
On Sun, Mar 16, 2008 at 7:19 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Yeah test_tokenize is weird, I've been looking into it as well. Here's a
> sample failure from a Windows buildbot:
> [failure log snipped...]
> On that first line, 'f' is lib/test/tokenize_tests.txt, so basically, it's
>
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>In 2.5.2 it prints
>
>
>
>
>Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
> always return a str?
I'd call this a bug. The change is an accident, a side-effect of the fact
that in 2.5.1
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>In 2.5.2 it prints
>
>
>
>
>Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
> always return a str?
I'd call this a bug. The change is an accident, a side-effect of the fact
that in 2.5.1
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I thought that might be what happened, but I couldn't remember if that
> optimisation was a 2.6 only change or not (I suspect it was included in
> 2.5 as a prereq to the spec compliance updates).
>
Exactly.
> Anyway, +1
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The isinstance(value, str) check in Py3k is too restrictive - it needs
> to accept bytes instances as well.
>
Hmm. There's not a lot of consistency here:
>>> int(b'1')
1
>>> float(b'1')
1.0
>>> complex(b'1')
Traceback (m
On Tue, Mar 25, 2008 at 11:57 AM, Facundo Batista <[EMAIL PROTECTED]>
wrote:
> 2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>:
>
> > So int and float accepts bytes, while complex, Decimal and Fraction do
> > not...
>
> I'm -1 to accept bytes as input for De
On Wed, Mar 26, 2008 at 2:57 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > I thought Decimal was going to be replaced by a C
> > implementation soon anyway. If so, is it worth going
> > to much trouble over this?
> >
>
> I believe that was found to be more trouble than it was
201 - 300 of 388 matches
Mail list logo
